For the full gory details of getting this up, see: bollwyvl#1

Build with coverage: https://github.com/bollwyvl/pythreejs/runs/1866129284

Some coverage: https://codecov.io/gh/bollwyvl/pythreejs

Nothing else planned here, probably ready for review!

@bollwyvl RTD is already working with GH Webhooks and RTD preview rendering in ipywidgets. No GH action needed.

Welp, the travis one (was) running the link check, so figured I'd bring it across. Can certainly take out, if it's already being run on RTD.

AFAI remember, the lint check step done on travis also checks links in markdown files and examples notebooks (and not just the docs).

Run with linkchecks of everything:
https://github.com/bollwyvl/pythreejs/runs/1879733287

Of note: i did try checking the individual anchors with --check-anchors, and a few things (well, hundreds) fail, as the docs structure changed some, and it doesn't appear the upstream has versioned docs. Turns out a bunch of them still work, as some clever clientside stuff redirects them... lil' ol pytest isn't going to be able to follow them.

https://threejs.org/docs/#api/geometries/BoxGeometry     # magically redirects to...
https://threejs.org/docs/#api/en/geometries/BoxGeometry

...but it would be a bit of a haul to get everything fully accurate, and it could well break again in the future...

The upstream docs are unfortunately not versioned either, so some inaccuracies are bound to happen either way 😞

Sorry for the commit spam, thought it would be quick update to pull in the #342 changes! 🤷

Some findings:

• the pyproject.toml build-system is basically incompatible with setupbase, as-is without hacks
  • it yields uninstallable sdists and can't be pip install . (-e might work... but...)
  • the workaround requires sys.path += [HERE] which is pretty much always a bad smell, but it works
• once all that was working, the only big difference was a doubling of the up-front time to ~3min
  • installing lab is pretty expensive (a few upstreams don't have whls)
    • the pip cache helps a bit (probably 30s)
    • could potentially save another 30s by caching the yarn packages, but without a yarn.lock...
  • the lab 3 install (without node or lab build) is pretty much as fast as the sdist install, which makes sense
• the link check cache wasn't doing quite what i wanted
  • now times out every week, but can pull from previous weeks, and update if needed

It would probably be good to get this in to shake down whatever else has to happen for a release...

the pyproject.toml build-system is basically incompatible with setupbase, as-is without hacks

Yes I've seen that locally as well. Removing the build_meta config value seems to work around that for now.

once all that was working, the only big difference was a doubling of the up-front time to ~3min

I'll give it a go to ensure that end-users are not going to see any increases. If the CI time is not being spent doing obvious "duplicate" work, I don't think this repo has a high enough activity level to spend too much time optimizing things.

installing lab is pretty expensive (a few upstreams don't have whls)

Yes, it would be good if the lab extension builder package could be a separate package with a minimal dependency tree, since it will be installed for all sdist installs as well. I also want to check that sdist installs work when node is not available on the system.

I also want to check that sdist installs work when node is not available on the system.

The 3.6 excursions all install from sdist, and have the assets:

https://github.com/bollwyvl/pythreejs/runs/1916098289?check_suite_focus=true#step:7:21581